The Data Dissemination Service is a background service which plays a key role in getting data from the ship out to remote clients. Its job is to handle the larger and less time sensitive type of data traffic.
This service does not send real-time data out for client visualization, that is the role of the SignalR Data hub.
When the SCS system attempts to send an email it routes all requests through this service. Email has become a very important means of communication, however with the removal of on board mail servers it has been difficult to reliably utilize it as internet connectivity is intermittent. The Data Dissemination Service attempts to resolve this by adding some resiliency to the send process.
Instead of a send-and-forget type approach, the service will attempt to send the email as requested but monitor for failure. In the event of failure the email is encrypted and serialized to storage. At regular intervals the service will attempt to reconnect to the [shore based] mail server, once a connection is successful an attempt is made to retry sending all prior failures. This cycle continues until every emailed queued up is successfully pushed to the mail server.
SCS only deals with SMTP on the ship, no IMAP services are provided.
Email settings can be modified in the Settings portion of the website.
While ACQ is in charge of calculating the data averages for all SAMOS interfaces, the Data Dissemination Service is in charge of taking those outputs and getting them to FSU. If enabled, the service has a nightly job which pulls all data from the prior day and packages it up in compliance with the SAMOS v1 packaging guidelines along with all relevant meta-data, file hashes and needed information. It then pushes the package to shore over to FSU for processing.
In the event a user requests a manual send of data the request is routed and processed through this service.
See also: SAMOS
While ACQ is in charge of recording the data from all TSG sensors, the Data Dissemination Service is in charge of taking those outputs and getting them to AOML. If enabled, the service has a nightly job which pulls all data from the prior day and packages it up in compliance with the AOML packaging guidelines along with all relevant meta-data and needed information. It then pushes the package to shore over to AOML for processing.
In the event a user requests a manual send of data the request is routed and processed through this service.
See also: TSG
While ACQ is in charge of recording the data from all sensors, the Data Dissemination Service is in charge of taking those outputs and getting them to NCEI. If enabled, the service has a nightly job which pulls all data from the prior day and packages it up in compliance with the NCEI NetCDF packaging guidelines along with all relevant meta-data and needed information. It then pushes the package to shore over to NCEI for processing. If applicable SCS may also update the OMAO Ship Daily Activity Tracking system (SDAT) to record the fact that the ship had submitted the day to shore officially transferring responsibility of the submission over to NCEI.
In the event a user requests a manual send of data the request is routed and processed through this service.
NOAA Ships may switch to using the local netman server and rSync instead of FTP to get datasets off the ship and to NCEI. If that is the case on your vessel then SCS will move the data to the netman server instead of FTP'ing it directly to NCEI. Once it is on the netman server (on the ship) SCS is no longer responsible for getting it to shore as control of that server is outside the scope / control of SCS.
See also: NCEI
The Data Dissemination Service is in charge of management of all Custom Message templates defined in the system. The service keeps track of all of these templates and enables/disables them as appropriate. It collects the appropriate sensor data, formats it as requested by the user and pushes it out as defined in the template. For this reason the Data Dissemination Service should be whitelisted in the local systems firewall as many of these templates push out via TCP/IP or UDP/IP.
See also: Custom Messages